Methods and systems for dispatching messages to mobile devices

ABSTRACT

A server includes a mail interface that can communicate messages using various formats and protocols to track down recipients of important messages. An automated dispatcher maintains dispatching rules that establish preferences for message routing. The dispatching rules distinguish between email, mobile-phone, and pager addresses and communication protocols and can be set to try different addresses and protocols to get a message to one or more recipients. Forwarded messages can be reformatted for the receiving device, while a copy of the original message is retained. Messages may be reformatted to include the phone number of the message sender. The reformatted message can then present the user with an option to return the message via a phone call. The reformatted message can include more than one phone number, in which case the sender&#39;s phone numbers can be prioritized for presentation to the user. The reformatted message can also present the user with an option to review notes or other contact-specific information prior to responding to the message.

REFERENCE TO CD APPENDIX

The CD Appendix, which is incorporated herein by this reference,contains the source code for an embodiment of the invention, features ofwhich are described below in connection with the drawings. The file thatincludes the source code is named “CD Appendix OG001.C1C1C3C1C1,” wascreated May 29, 2013, and is 4,430 KB. The copyright owner of thematerial in the CD Appendix has no objection to the facsimilereproduction by anyone of the patent document or the patent disclosure,as it appears in the Patent and Trademark Office files and records, butotherwise reserves all copyright rights.

BACKGROUND AND SUMMARY

Many computer users maintain a number of different email accounts. Forexample, many users have separate accounts for home and work.Unfortunately, maintaining more than one account can be cumbersome,often requiring the user to check his or her mail at more than onelocation. A communications server in accordance with the inventionsimplifies this process by automatically collecting all of the messagesfrom two or more email sources and presenting the collection to theuser.

Some conventional mail systems collect mail from various sources.However, such systems do not work in many cases in which one of theemail sources is a client connected to the mail system via a protectivefirewall. In such cases, the firewall will not allow the mail collectionsystems to pull mail from the protected client. To address this problem,an embodiment of the invention includes a mail agent that can be addedto a protected client to instruct the client to periodically pushmessages to the mail system. The mail system is therefore not limited tomail collection from sources on the same network, and can thereforeprovide the user with a complete listing of the user's mail from asingle location.

In addition to providing the user access to a number of mail sources,one embodiment of the invention dispatches messages to an appropriatereceiving device based on the user's needs, as specified by the user.For example, a communications server in accordance with one embodimentcan be configured to dispatch important messages to a wireless device,such as a mobile phone or pager.

Forwarded messages are automatically reformatted for the receivingdevice, while a copy of the original message is retained. The retainedcopy can be viewed later if the user is interested in message contentthat is incompatible with the wireless device. The user can also use thewireless device to forward the original message to another receivingdevice. In the case of forwarding, the saved original message and notthe reformatted message is sent to the forwarding address.

In one embodiment messages are reformatted to include a phone number ofthe message sender. The reformatted message, when conveyed to the user'smobile phone, can then present the user with an option to return themessage by calling the sender. The reformatted message can include morethan one phone number. In some embodiments the sender's phone numbersare prioritized for presentation to the user. For example, the sender'swork number might have a higher priority than the sender's work numberduring working hours.

In another embodiment messages are reformatted to include a link tocontact information for the message sender. The reformatted message,when conveyed to the user's mobile phone, can then present the user withan option to review the contact information prior to responding to themessage. The contact information can include e.g. the sender's nickname,address, phone numbers, and general notes that might be of interest tothe recipient.

Some conventional email services collect messages from various mailsources, allowing users to receive both messages directed to a user'swork address and messages directed to a user's home address, forexample. When the user then responds to these messages, a single emailaddress identifies the source of the reply. Assume, for example, that auser is assigned that user address “user@home” for a personal emailaccount and “user@work” for a work-related email account. Further assumethat the user's email systems collects mail directed to both the workand home accounts, allowing the user to respond to personal andwork-related messages from home. The user responding from home to acollection of work-related email messages will typically respond to eachmessage as “user@home.” Subsequent replies from the user's responsemessage will then be directed to the user's home address, even if theoriginal message was directed to the user's work account. This failureto maintain the user's separate identities can be problematic, as theuser will not be able to effectively categorize messages if the user'swork and home identities are not preserved. An embodiment of theinvention addresses this problem, allowing a user to easily maintainseparate user identities.

In one embodiment that forwards messages to wireless devices, if theuser's mobile phone is unavailable, then the original message isreformatted and forwarded to the user's pager. This embodiment isbeneficial, particularly for urgent messages, as pagers generallyprovide a more robust means of communication than do mobile phones.

This summary does not limit the claims, which are defined instead by theclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a system 100 in accordance with an embodiment of thepresent invention.

FIG. 2 depicts system 100 FIG. 1, showing client 145 and communicationsserver 105 in more detail, while eliminating other features forsimplicity.

FIG. 3 depicts a “screen shot” of a form 300 that allows the user tospecify an email source account and choose a corresponding color.

FIG. 4 is a flowchart 400 depicting the manner in which communicationsserver 105 maintains user identities when the user responds to emailmessages directed to different ones of the user's identities.

FIG. 5 is a flowchart 500 depicting the message polling method employedby mail poller 152 of FIG. 2.

FIG. 6 is a screen shot depicting an HTML form 600 that a user fills into establish a new mail filter rule.

FIG. 7 is a block diagram of dispatcher 154 of FIGS. 1 and 2.

FIG. 8 depicts an HTML form 800 that the user has filled out so thatdispatcher 154 forwards all urgent messages from co-workers if thosemessages are received on a Sunday.

FIG. 9 depicts an HTML form 900 that the user fills out to register awireless receiving device, such as a pager or mobile phone, so thatdispatcher 154 can forward messages to the device.

FIG. 10 is a flowchart 1000 depicting an operation of dispatcher 154 inthe event the user has specified a dispatch rule as depicted in FIG. 8.

DETAILED DESCRIPTION

FIG. 1 depicts a system 100 in accordance with an embodiment of thepresent invention. System 100 includes a number of entities thatcommunicate with one another over a large network, such as the Internet.In FIG. 1, dotted lines terminating in arrows represent communicationsthat can take place over the Internet. System 100 includes acommunications server 105, an intranet 110, a pair of mail servers 115and 120, a laptop computer 125 hardwired to the Internet via a localline 130 and a modem 132, and a cell transceiver 135 adapted tocommunicate with a wireless device 140, such as a cell phone thatcommunicates via the conventional Wireless Application Protocol (WAP).

As is conventional, intranet 110 is a network designed for informationprocessing within an organization. Intranet 110 typically employsapplications that allow users to communicate with others within intranet110 and, via the Internet, with others outside of intranet 110. Suchapplications typically include Web browsers and email programs. Intranet110 includes a local server 143, a number of clients 145-147, and afirewall 149. Clients 145-147 communicate with one another withinintranet 110 without their messages traversing firewall 149. Firewall149 is a conventional security system intended to protect anorganization's network against external threats available over theInternet. Among other things, firewall 149 prevents clients 145-147 fromcommunicating directly with communications server 105 and other entitieson the Internet.

Communications server 105 includes a mail interface 150, a mail poller152, and a dispatcher 154. Mail poller 152 polls various email sources,such as servers 115 and 120, to consolidate messages from differentinformation sources that are all assigned to the same user. Messages maybe simple, plain text messages, or may include attachments. In oneembodiment messages are MIME encoded.

The examples presented in connection with FIGS. 1-3 assume that singleuser “USER” maintains three email accounts. The first, “user@work,”resides on local server 143 and may be accessed by the user via client145. The second, “user@home,” is a personal account stored on server 115that the user distributes to family and friends for personalcorrespondence. Finally, the third, “user@play,” is another emailaccount stored on server 120 that the user maintains to communicate withother users that may share a hobby, for example. These examples areillustrative; network users often have numerous email accounts for anynumber of reasons.

Messages for use in one embodiment of the invention are encoded usingthe well-known Simple Mail Transfer Protocol (SMTP). Servers 115 and 120typically communicate messages using the POP3 post-office protocol, butmay also use the more recent Internet Message Access Protocol (IMAP).Both POP3 and IMAP employ SMTP to communicate between client and server.

In addition to collecting messages from the various email sources viapoller 152, mail interface 150 is adapted to periodically receivemessages pushed through firewall 149 to communications server 105, forexample from client 145. In one embodiment, client 145 is adapted toinclude a software application that periodically pushes messages fromclient 145 to mail interface 150. The application is often necessary, asmail interface 150 cannot poll client 145 through firewall 149.Consequently, the user would not have access to mail stored on client145 unless the user had access to the client on intranet 110. This is aproblem, for example, when the user is away from the office andattempting to retrieve his or her messages using laptop 125, forexample. The portion of the attached source code that includes theclient-side plug-in enabling the email push is:“src/skywalker/accessors/desktop/desktopagent.” (pp. 294-393). Theportion of the attached source code that includes the correspondingserver-side code is: “src/skywalker/accessors/desktop/server” (pp.289-293).

The user configures mail interface 150 to collect all messagesassociated with the three user mail accounts by receiving pushedmessages from client 145 and by polling for messages on servers 115 and120. Communications server 105 can then be accessed by the user usingany number of message-receiving devices, such as client 145, laptop 125,or wireless device 140. The user can thus retrieve all of his or hermessages from any device that provides Internet access.

In addition to providing the user access to a number of mail sources,communications server 105 dispatches messages to an appropriatereceiving device based on the user's needs, as specified by the user tocommunications server 105. For example, communications server 105 can beconfigured so that dispatcher 154 dispatches messages flagged as urgentto wireless device 140 via cell receiver 135. Messages flagged as“urgent” need not include the term “urgent,” but include some portion ofthe message that identifies the message as having a higher priority thanother messages. Other dispatch criteria are discussed below inconnection with FIG. 8.

FIG. 2 depicts system 100 FIG. 1, showing client 145 and communicationsserver 105 in more detail, while eliminating other features forsimplicity. As shown, client 145 includes a mail program 200 and a mailagent 205. As noted above, communications server 105 polls multipleinformation sources to consolidate user messages directed to differentaddresses assigned to a user. Mail polling is not new; however, Internetservers are believed to be unable to consolidate all types of usermessages because firewalls such as firewall 149 of the Internet 110preclude servers from polling messages from intranet clients such asclient 145. Applicants therefore extended conventional mail program 200to include a mail agent 205. Mail agent 205 periodically pushes messagescollected by agent 205 to mail poller 152 of communications server 105.The program modules specific to poller 152 are preceded by “packageskywalker.apps.email.”

Mail poller 152 includes a polling engine 210 and a filter or filters215. Polling engine 210 periodically downloads the user messages fromservers 115 and 120 and conveys the messages to filter 215. Filter 215applies blocking and filtering rules to the polled messages from pollingengine 215 and to any messages obtained from agent 205. Messages thatmake it through filter 215 are conveyed to mail application 217, and arepossibly dispatched to an appropriate user device using a dispatcher220. Mail application 217 presents the received new messages to the userusing a user interface 222.

User interface 222 presents the messages to the user, segregating themessages based on source. For example, messages from “user@home” may beassociated with a different color than messages from “user@work” or“user@play.” FIG. 3 depicts a “screen shot” of a form 300 that allowsthe user to specify an email source account and choose a correspondingcolor. Mail application 217, identified as “MailFrontHandler” in theattached source code, handles interfacing with the user over variousdevices. Mail application 217, in conjunction with user interface 222,allows the user to interact with communications server 105 to send andretrieve mail and to configure the collection of user-specific variablesthat control message filtering, dispatching, and blocking. Mailapplication 217 supports HyperText Markup Language (HTML) to communicateforms and documents. Mail application 217 also supports Wireless MarkupLanguage (WML) and Handheld Device Markup Language (HTML) to formatcontent for Web-enabled mobile phones.

A user accesses communications server 105 over a conventionalconnection, such as an Internet connection 224. A user-management andauthentication module 226 communicates with the user, verifying theuser's personal identity and allowing the user to configure his or hermail settings. Configuration information is stored in a profile server230 within communications server 105. Although not shown in FIG. 2, usermanagement and authentication module 226 also facilitates communicationwith the user via wireless devices, such as cellular phones. Theportions of the attached source code that deal with user management andauthentication module 226 are prefaced with “MainServLet” for HTML andprefaced with “ephone” for wireless devices.

Conventional email services collect messages from various sources,allowing users to receive messages directed to a work address andmessages directed to a home address, for example. When the user thenresponds to these messages, a single email address identifies the sourceof the reply. For example, a user responding from home to a collectionof work-related email messages will respond to each message as“user@home.” Subsequent replies from the original message sources willthen be directed to the user's home address.

For example, if a collection of messages includes one from the user'semployer directed to “user@work” and another from a family memberdirected to “user@home,” then the user will respond to both messageseither as “user@work” or “user@home,” depending upon whether the userresponded from home or from work. This can be problematic, as the userwill not be able to effectively filter messages based on identity if theuser's identities are not preserved, regardless of the account fromwhich the user responds to messages. Thus, if the user's employer sendsa message to “user@work,” then user will want to respond as “user@work,”and if a family member sends a message to “user@home,” then the userwill want to respond as “user@home.” Some mail systems allow the user tomanually change the “from” address of messages; unfortunately, manuallyswitching between address is cumbersome and invites errors. Anembodiment of the invention addresses this problem, allowing a user toeasily maintain separate identities.

FIG. 4 is a flowchart 400 depicting the manner in which communicationsserver 105 maintains user identities when the user responds to emailmessages directed to different ones of the user's identities.Communications server 105 organizes incoming messages by theirrespective destination addresses. Thus, messages directed to user@homewould be stored in directory locations associated with the user's “home”identity, while messages directed to user@work would be stored indirectory locations associated with the user's “work” identity.Communications server 105 then replies to messages using the destinationaddress associated with the respective identity. Alternatively, mailapplication 217 can save the “to” field from incoming messages and usethis information to identify the author of message replies. This methodis not preferred, however, as the “to” field can sometimes incorrectlyidentify a message recipient.

Referring again to the example of FIG. 4, assume that “Nicole@yahoo”sent a message No. 1 to “user@home,” and that “Alyssa@play” sent amessage No. 2 to “user@play.” Communications server 105 stores each ofmessages No. 1 and No. 2, depicting each in a manner that identifies thesource address to the user. In the example, message #1 is green toindicate that message #1 was directed to the user's home address, andmessage #2 is red to indicate that message #2 was directed to the user'splay address. The chosen colors are arbitrary, and other colors anddistinctions can be used to distinguish messages.

Should the user initiate a response to either message (by selecting areply icon 410, for example), the user's reply identifies the sender ashaving the email address to which the original message was directed. Inthe example of FIG. 4, the reply to “Alyssa@play” (to mail server 120)is identified as being from “user@play” and the reply to “Nicole@yahoo”(to a yahoo mail server 405) is identified as being from “user@home,”even though both replies are from the same server 105. Server 105 neednot be associated with any of the depicted mail servers 115, 120, or405, but may have an entirely different path name. Alternatively,servers 115 and 120 may be “native” servers that are part of server 105.Reply icon 410 is a conventional “button” linked to a selected one ofthe first and second messages. Many other methods of initiating messagereplies will be obvious to those of skill in the art.

A message can be reformatted to present the recipient an option to replyto the message by calling the sender, which option is identified here asa second reply icon 412. In some embodiments, database 230 (FIG. 2)includes an address book for each user. Each address book maintains alist of contacts for the user and includes various fields for eachcontact, including contact names, email addresses, phone numbers, notes,etc. A portion of the attached source code that deals with contactfields begins on Page 9 of 1078 with the line entitled “CREATE TABLECONTACTS (NICKNAME VARCHAR(40) NOT NULL.”

Reformatted messages can present the recipient user with an option toreturn the message by calling the sender. Portions of the attachedsource code that support this aspect of the invention begin on Page 400of 1078 with the line “//Get Phone Number to dial—Priorities are: 1)Cellular, 2) Work, 3) Home,” and on Page 439 of 1078 with the line“//look up contact phone message based on From field of email message.”Further, the call to the function that inserts the sender's phone numberinto the message is entitled “fromcontact.getPhoneBack( )” and isdetailed beginning at page 696 of 1078 in the source code.

The reformatted message can include more than one phone number. In someembodiments the sender's phone numbers are prioritized for presentationto the user. This aspect is also discussed in the attached source codeat pages 400 and 439.

In another embodiment messages are reformatted to include a link tocontact information specific to the message sender. The reformattedmessage, when conveyed to the user's mobile phone, can then present theuser with an option to review the contact information prior toresponding to the message. The contact information can include e.g.notes about the sender that might be of interest to the recipient.Contact-specific information in accordance with one embodiment is listedin the attached source code at Page 393 of 1078 beginning at line“package skywalker.apps.contacts.frontend.”

In addition to providing an option to reply to a message via a phonecall, message are also reformatted to support the following useroptions: “Reply”: reply to the message with a message to the sender;“Reply All”: reply to the message with a message to the sender and allmessage recipients; “Forward”: forward the message to a recipient of theuser's choosing; “Add Contact”: add the sender's contact information tothe user's address book; “Delete”: delete the message. These featuresare supported e.g. on page 1072 in the attached source code beginning atthe line entitled “<option onpick=”#replymenu“>Reply</option>.” In someembodiments selecting “Reply” may present the user alternative replyoptions, allowing the message recipient to reply via email or byselecting from among a list of phone numbers.

FIG. 5 is a flowchart 500 depicting the message polling method employedby mail poller 152 of FIG. 2. Poller 152 retrieves, parses, and filtersmail messages received from disparate sources. Poller 152 acquires therequisite user-specific information to perform these functions fromdatabase 230, the contents of which the user can manipulate via mailapplication 217.

Three events trigger mail polling. The first event is the beginning ofwhat is known as the “polling interval.” In one embodiment, externalemail sources are polled every 15 minutes and native mail sources everytwo minutes, regardless of whether the user is currently logged ontocommunications server 105. The user may also initiate polling either bylogging on to server 105 or by selecting a “get messages” button on amessage-view screen.

Regardless of the way in which polling is initiated, when firsttriggered, poller 152 takes the user's information from database 230,logs onto the first server listed (step 505), and obtains the firstmessage on the server (step 505).

Each message has a unique identifier (UID). Poller 152 reads the message(step 507) and determines whether the UID is already listed in database230 (step 509). If not, the message is a new one, and is therefore addedto the list of messages in database 230 (step 511). Also in step 511,the message is marked to indicate that the message exists locally and ona remote server. As discussed below, this marking scheme enables poller152 to synchronize the contents of the local and remote mail servers.

If the user is currently logged onto communications server 105, acircumstance termed “in session,” the entire contents of the message,including any attachments, are cached (step 515) in database 230.Caching renders the message content available to the user as soon as themessage appears in the user's “in-box.” Next, filter 215 determineswhether the message meets the requirements of a blocked message (step517). If so, then the message is unmarked (step 519), causing themessage to be deleted at a later step. If, on the other hand, themessage is not blocked in step 517, then filter 215 determines whetherthe message should be dispatched to another device, such as another mailaccount, a mobile phone, or pager. If so, then dispatcher 220 dispatchesthe message to the appropriate device (step 521).

In the attached source code, message dispatching, filtering, andblocking are collectively performed by a Filtering And Routing Engine(FARE). In that embodiment, after obtaining messages the poller does aprocedure call on a FARE module called “fareworker.java,” passing themessages as arguments. The FARE module then employs user-specific filtervariables (e.g., from database 230 of FIG. 2) to filter and dispatch themessages.

Returning to flowchart 500, whether the message is dispatched or not,poller 152 then sends the UID and the message header to the localmessage database in database 230 (step 523) and looks for more messages(step 525). Additional messages are treated in the same manner as thefirst message. If there are no more messages, then the process moves tostep 527, during which unmarked messages are deleted. Unmarked messagesinclude those that were blocked in step 517.

Having read all the messages from the first remote server, poller 152checks database 230 to determine whether there are more email sources tobe polled (step 529). If so, then poller 152 reads the next source (step531) and returns to step 507.

The first example assumed that the message had not yet been read bypoller 152. Periodic polling often results in poller 152 readingmessages multiple times. Previously read messages are dealt with in adifferent way. Steps 505 and 507 are the same for previously readmessages. In step 509, however, the UID will already have been listed sothe process will move to step 513, during which the message is marked.If the user is in session (step 533), then the entire contents of themessage, including any attachments, will be cached to allow the userimmediate access to the content (steps 535 and 537). Since the messagehad been dealt with previously, there is no need to determine whetherthe message should be blocked or filtered. Consequently, the processmoves to step 525.

The foregoing processes for new and old messages will continue until allof the messages on a given server have been processed. Once there are nomore messages in the server, the process moves to step 527, in which allof the unmarked messages are deleted. These messages will include thosethat were blocked in step 517 and those that were not marked in steps511 and 513. The unmarked messages will be either blocked messages orthose that have been deleted at the source, and that should consequentlybe deleted in the local server. The entire process will then be repeatedfor each message source listed in database 230.

Once the message sources have been processed, poller 152 goes dormantuntil the next time polling is initiated. If the user is in session,then the message headers are displayed in step 541. The entire messagesmay also be displayed when prompted by the user (step 531). If the useris not in session, then nothing happens (step 545) until the user logson or periodic polling is initiated.

In accordance with another embodiment, the entire message polled fromthe remote server (for example, remote server 115) is not cached ineither step 515 or step 537, but rather is stored within database 230.In addition, messages that are deleted from the remote server are notmarked for deletion on the local server in step 511 and 513, andconsequently are not deleted in step 527. Communications server 105saves the UIDs of messages deleted at communications server 105. Thenext time communications server 105 polls for messages, those messagesidentified with a deleted UID are not displayed to the user.Communications server 105 retains the UIDs of messages deleted fromdatabase 230 until those messages are also deleted at the source (e.g.,deleted from remote server 115).

FIG. 6 is a screen shot depicting an HTML form 600 that a user fills into establish a new mail filter rule. Form 600 appears when the userclicks on an “Add Blocking Filter” button. As is apparent from thescreen shot, the user may block mail messages based on the sender, thesubject, the mail source, the priority level, and/or the time at whichthe message was sent.

The “Filter Title” field in form 600 is purely for user interface, andis not part of the filtering algorithm. Polling engine 210 willgenerally have already sorted the messages by source (e.g., user@homevs. user@work), so the specified mail servers control polling engine210, and do not control filter 215. This distinction is transparent tothe user.

Mail poller 152 blocks any message that matches any criterion of filter215. The criteria in any one filter are applied as a group usingtop-to-bottom inheritance. For example, the definition shown in FIG. 6would block all low-priority messages sent during any weekday.

When mail poller 152 encounters a match, mail poller 152 blocks themessage without further tests. Mail poller 152 then stores the messageUID of the blocked message in the user database for future reference.For a message retrieved from a remote mail server, where a copy stillexists, the message header and body are flushed permanently from localmemory. If a blocked message is retrieved from native mail (in whichcase no backup copy would otherwise exist), the message is placed intothe user's deleted mail folder.

If the message passes all the blocking filters, mail poller 152 storesboth its UID and its header in database 230. In addition, if thisparticular call is taking place while the user is in session, themessage body and attachments are cached for the duration of the session.

Filter 215 in mail poller 152 looks for stream patterns in the “from”and “subject” fields. Streams are case-insensitive. The filter stringneed not be identical to the corresponding portion of the message, butthe corresponding portion of the message must include the string. Forexample, if a message's “from” field reads:

“John Q. Doe”<jdoe1277@aol.com>, then “Doe”, “@aol.com”, and “e12” yielda match. Conversely, “John Doe” and “America Online” will not yield amatch. It is important to note that is possible to block an entiredomain by specifying something like “aol” in the “sender” yield.

Filter 215 matches priorities using the “X-priority” field associatedwith conventional email messages. In database 230, the values for high,medium, and low priority are specified as 1, 0, and −1, respectively.

FIG. 7 is a block diagram of dispatcher 154 of FIGS. 1 and 2. Dispatcher154 includes a dispatching filter 700, a message renderer 705, and amessage hound 710.

Dispatching filter 700 allows the user to specify one or more forwardingaddresses for messages that meet particular filtering requirements. FIG.8 depicts an HTML form 800 that the user has filled out so thatdispatcher 154 forwards all urgent messages from co-workers if thosemessages are received on a Sunday. Before such dispatching can beaccomplished, the user must enter a description of the device to whichthe messages are to be forwarded. FIG. 9 depicts an HTML form 900 thatthe user fills out to register a wireless receiving device, such as apager or mobile phone, so that dispatcher 154 can forward messages tothe device.

Form 900 allows the user to include the contents of the subject field,the identities of other users to whom the message was directed, and alimited number of characters from within the message body. This aspectof form 900 is sometimes important for pagers, because some pagercompanies charge based on the amount of information conveyed to device.In the example of FIG. 9, the wireless device is a mobile phone, andmessage renderer 705 is instructed to include: 1) the subject, 2) theidentities of other users receiving the message, and 3) up to 700characters within the body of the message.

Message renderer 705 allows users to set different dispatch parametersfor different devices. For example, message renderer 705 may beconfigured to send less information to a pager than to a cellular phone,and to forward the entire contents of the message, including anyattachments, if the message is forwarded to a personal computer orlaptop. Renderer 705 also reformats messages as necessary to forwardsome or the entire message content to selected target receiving devices.In a typical example, a user may configure renderer 705 to forward onlythe subject and sender of important messages to the user's mobile phone.

In one embodiment message renderer 705 can reformat messages to includethe phone number of the message sender. The reformatted message, whenconveyed to the user's mobile phone, can then present the user with anoption to return the message via a phone call. Where database 230includes more than one phone number for the sender, the reformattedmessage can include more than one phone number. In some embodimentsmessage renderer 705 prioritizes the sender's phone numbers forpresentation to the user. Message renderer 705 can also reformat themessage to include additional information about the contact, such asnotes about the sender that might be of interest to the messagerecipient. These and other reply options are noted above.

The final element of dispatcher 154 is message hound 710. Message hound710 can be configured by the user to establish a hierarchy of devices towhich selected messages might be forwarded. For example, the user canconfigure message hound 710 to forward all urgent messages to a mobilephone and, in the event that the mobile phone is turned off or otherwiseout of service, then to send the same or a smaller version of themessage to the user's pager. Message hound 710 can also be configured toinclude another email address, such as that of the user's secretary, inthe hierarchy.

FIG. 10 is a flowchart 1000 depicting an operation of dispatcher 154 inthe event the user has specified a dispatch rule as depicted in FIG. 8.In the attached source code, the method for dispatcher 154 is“forwardMessage” in the file “FareWorker” in the source code of theattached CD Appendix.

At step 1005, the user has filled out and submitted form 800, andconsequently conveyed the information of form 800 to database 230 (FIG.2). Dispatcher 154, using the information stored in database 230,subjects subsequently received unblocked messages (step 1010, from step517 of flowchart 500 of FIG. 5) to the rules defined using form 800(decision 1015). If the message meets the rules, then a version of thereceived message should be sent to the user's mobile phone. Regardlessof whether the message meets the rules, the message's UID and header areadded to the user's database (step 1020). Step 1020 is the same stepidentified at step 523 in FIG. 5.

If the message is to be forwarded to the user's mobile phone, dispatcher154 first attempts to contact the specified phone (step 1025). Thisattempt is made using the Short Messaging Service (SMS) protocol, aconventional protocol adapted for sending short messages to pagers andphones. Using SMS, dispatcher 154 can send a short alphanumeric messageto the user's mobile phone.

Per decision 1030, if the user's phone is unavailable (for example,where the phone is turned off or out of the service area), oneembodiment of the invention reformats the message for receipt by a pager(step 1035) and then sends the reformatted message to the user's pager(step 1045). This embodiment is beneficial, as pagers generally providea more robust means of communication than do mobile phones.

Returning to decision 1030, if the mobile phone is available, themessage is reformatted as necessary for transmission to the user'scellular phone (step 1040), in which case the reformatted message mayinclude a reply number for the sender of the received message. Finally,the reformatted message is sent to the user's cellular phone (step1050).

The entire message is preserved in the user's database regardless ofwhether all or a portion of the message is conveyed to one of the user'swireless devices. The user can therefore access the complete messagelater from e.g. a personal computer. Additionally, mail application 217(FIG. 2) responds to instructions from a mobile phone to forward areformatted message by forwarding the original message stored indatabase 230. The recipient of the forwarded message is therefore notlimited by the capabilities of the forwarding device. For example, auser away from his or her office may forward an urgent messagecontaining an attachment to a nearby computer for viewing or printing.The code that supports this type of forwarding is identified at pages446-469 of the attached source code as “PhoneComposeMessageHandler.”

Message hound 710 can be set to dispatch messages to the next listeddevice upon receipt of a failure-to-deliver message, or can be set todispatch the message if the intended recipient does not respond within agiven time period. SMTP and WAP can be implemented to let the senderknow whether the intended recipient received a message. One embodimentuses this information to report success or failure to the sender. Forexample, mail application 217 might report that the user's mobile phonewas out of service and the user's pager has been alerted.

The foregoing specification and figures are high-level descriptions ofsome embodiments of the invention. The attached annotated source codedetails a specific embodiment. The code executes on a Solaris Sparcworkstation on a UNIX platform. The messages, user preferences, emailsources, and UIDs are stored on a database server, in one embodiment aMicrosoft SQL server running on a Windows NT server machine.

While the present invention has been described in connection withspecific embodiments, variations of these embodiments will be obvious tothose of ordinary skill in the art. For example, polling can be extendedfrom mail sources to other info, such as local weather, sports, or stockquotes. Each embodiment extends to both methods as well as to structuresand devices that carry out the methods. Therefore, the spirit and scopeof the appended claims should not be limited to the foregoingdescription.

What is claimed is:
 1. A computer-implemented method of dispatching anelectronic message, the method comprising: maintaining a database withdispatching rules establishing preferences for message routing, at leastone dispatching rule operable to distinguish between a serverdestination associated with a recipient and specified by a firstdestination address and a mobile-phone destination specified by a seconddestination address; and determining whether the recipient responds tothe message directed to the server destination specified by the firstdestination address and, if the recipient fails to respond to themessage via the server destination, sending the message to themobile-phone destination specified by the second destination address. 2.The method of claim 1, wherein the first destination address comprisesan email address associated with the recipient.
 3. The method of claim2, wherein message comprises an SMS message.
 4. The method of claim 2,wherein the second destination address is associated with a secondrecipient.
 5. The method of claim 4, further comprising reportingsuccessful receipt of the message by the second recipient.
 6. The methodof claim 1, further comprising sending the message to a pager absent aresponse to the message from at least one of the server destination orthe mobile-phone destination.
 7. The method of claim 1, whereindetermining whether the recipient responds to the message directed tothe server destination comprises at least one of receiving afailure-to-deliver message or awaiting a given time period withoutreceiving a response from the recipient.
 8. The method of claim 1,further comprising reporting successful receipt of the message.
 9. Themethod of claim 1, further comprising reporting failure of receipt ofthe message.
 10. The method of claim 1, wherein the server destinationcommunicates the message using SMTP and the mobile-phone destinationcommunicates the message using SMS.
 11. The method of claim 1, furthercomprising determining whether the mobile-phone destination is availableand, if the mobile-phone destination is not available, dispatching themessage to a third destination address.
 12. The method of claim 1,further comprising altering the dispatching rules responsive to acommand from the mobile-phone destination.
 13. The method of claim 1,wherein the message includes a priority field, the method furthercomprising examining the message other than the priority field forindicia of priority and determining whether to send the message based onthe indicia of priority.
 14. A non-transitory computer-readable mediumhaving computer-executable instructions for performing the method ofclaim
 1. 15. A server comprising: a mail interface operable tocommunicate email messages; and a dispatcher coupled to the mailinterface, the dispatcher maintaining dispatching rules establishingpreferences for message routing, at least one dispatching rule operableto distinguish between an email destination associated with a recipientand specified by a first destination address and a mobile-phonedestination specified by a second destination address; wherein thedispatcher determines whether the recipient responds to the messagedirected to the email destination specified by the first destinationaddress and, if the recipient fails to respond to the message via theemail destination, sends the message to the mobile-phone destinationspecified by the second destination address.
 16. The server of claim 15,wherein the dispatcher reformats the message before sending the messageto the mobile-phone destination.
 17. The server of claim 16, wherein thesecond destination address is associated with the recipient.
 18. Theserver of claim 16, wherein the second destination address is associatedwith a second recipient.
 19. The server of claim 18, wherein thedispatcher reports successful receipt of the message by the secondrecipient to a sender of the message.
 20. The server of claim 14,wherein the dispatcher reports successful receipt of the message by therecipient to a sender of the message.